iT邦幫忙

2026 iThome 鐵人賽

DAY 12
0
AI Engineering

它說得頭頭是道系列 第 18 篇

# Day 18 — 知識散在八個地方,而其中一份已經沒了

  • 分享至 

  • xImage
  •  

昨天定了路線:事實要在建置的時候先整理好。

那接下來就是一個非常實際的問題:

這些事實,現在到底在哪裡?

我列了一遍,然後有點傻眼。


清單

在哪裡 放的是什麼 抓得到嗎
票卡系統(兩套) 需求、決策、實作紀錄、驗證結果 ✅ 有 API,寫了腳本
程式碼儲存庫 現在真正在跑的東西 ✅ 直接讀
內部 wiki 維運相關 ⛔ 刻意不碰(Day 12)
Notion 部分規劃與整理 ⚠️ 有,但沒接
協作筆記工具 會議中長出來的東西 ⚠️ 有,但沒接
Figma 設計稿、流程圖 ⚠️ 圖為主,難抽成文字
某個 RD 自己架的網站 一張系統架構圖 ⚠️ 在別人的地盤上
各種 Excel 規劃功能時的表格 ⚠️ 散落,沒有固定位置
人的腦袋 為什麼當初這樣決定 ❌ 抓不到

八個地方,而我實際接上的只有前兩個。


先講接上的那兩個

我寫了兩支抓取腳本,做的事情很單純:把票卡完整地拉下來,存成本地檔案。

重點在「完整」兩個字——不只是標題和狀態,還要描述、每一則留言、時間、誰寫的。因為 Day 11 講過,理由都藏在留言裡。

這裡踩到一個坑,我覺得值得講,因為它很典型:

我原本用的那組工具,在寫入描述的時候有 2048 字元的上限。

超過的部分不會報錯,它就是沒有了。

沒有錯誤訊息、沒有警告。你以為寫進去了,實際上後面被切掉。

這件事跟 Day 16 講的「一次餵太多它會靜靜丟掉一部分」是同一個形狀——失敗的時候沒有聲音,是最難抓的那一種。

後來換了另一組工具才能寫完整。

而抓下來之後,第一個發現是:資料會舊

這條是我用三次事故換來的。

我在那支「重跑整條資料鏈」的腳本開頭,自己寫了一段註解,現在看起來像自白:

已經栽過三次在「資料太舊」上——

  1. 程式碼儲存庫停在某一天,新的卡片查不到對應的提交紀錄
  2. 程式碼裡的註解過時,而人工整理的文件抄了那些過期的話
  3. 票卡停在幾天前,某一張新卡整個查不到

每次都是查半天才發現,不是工具壞,是資料舊。

三次都是同一個症狀:我以為東西壞了,其實是我手上那份是舊的。

所以那支腳本現在會在最後印出每一個來源的新鮮度,超過兩天就標警告。

這不是效能優化,這是為了不要再浪費半天。


但這篇真正想講的是抓不到的那些

上面那些都還算工程問題。接下來這段不是。

有一份東西,已經沒了

以前有一位 RD 做過一張系統架構圖,畫的是其中一個產品的整體結構。

那張圖現在找不到了。

不是被刪掉的。 是因為人員調動,那份東西就跟著沒了——沒有人明確地決定要丟掉它,它只是停在某個沒有人再打開的地方,然後跟著那個人的離開一起變成不存在。

我想強調這件事的性質:

它不是一次資料遺失事故。沒有人犯錯,沒有系統掛掉。

它只是……跟著一個人走了。

而現在還有一張,狀況一模一樣

現在也有一張架構圖,畫的是另一個產品,做得很好。

它放在那位 RD 自己架的網站上。

我想講清楚我的意思:那不是誰的錯,那是最自然的做法。你做了一個東西,放在自己方便的地方,這很正常。

但如果我把前一張圖的故事擺在旁邊看:

這張圖現在存在的條件,跟那張已經不見的圖,是完全一樣的。

它現在好好的。而它會不會繼續在,取決於一個跟內容品質完全無關的東西。


最難的那一類:從來沒有被寫下來過

清單最後一行是「人的腦袋」,而那一行沒有辦法用任何腳本解決。

規劃一個功能的時候,很多決定是在對話裡發生的:為什麼選這個方案、為什麼排除那個、為什麼這裡要特別處理。有些會留在 Excel 上,有些留在訊息裡,而有些就只是講過一次。

Day 3 我寫過,這一類裡面最貴的是被否決的決定——「我們考慮過 X,但因為 Y 所以沒做」。這種東西不會出現在任何一個系統裡,因為沒有產出物。沒有卡片、沒有程式碼、沒有畫面。

它只存在於「當時在場的人」腦袋裡。


而這件事現在對我來說不是抽象的

寫這個系列到目前為止,我講的大部分是已經發生的事。這一段不是。

團隊裡有一位待了很久、而且是目前最了解專案的同事,要離開了。

我很怕。

不是怕某一份檔案不見——檔案還可以找。我怕的是那些從來沒有變成檔案的東西:為什麼這個流程長這樣、那個例外是為了誰開的、三年前那個決定背後到底是什麼考量。

Day 3 我寫過一句話:

知識綁在「誰比較熟」身上,而那個綁法只要一個人離開,就整塊歸零。

那時候那句話是一個論點。

現在它有日期了。


那能做什麼?

我必須誠實:我沒有辦法在剩下的時間裡,把一個人累積那麼久的東西抓下來。 那不是工程問題,那個量級也不是腳本能解決的。

但我後來想到,至少有一件事可以做得比較對——問題要問對。

因為「你知道哪些東西?」這個問題,是答不出來的。一個人不會知道自己知道什麼——那些東西太理所當然了,理所當然到根本不覺得需要講。

比較有機會問出東西的,是很具體的那種:

  • 哪些事情,只有你知道為什麼?
  • 有沒有哪個流程,新人照著做一定會踩雷?
  • 我們有沒有考慮過什麼方案,後來決定不做的?

第三個問題就是 Day 3 那張表上「PM 那一組」的來源。當時我以為我在設計一個查詢功能。

現在我覺得,那其實是一張離職交接表。


所以這篇的結論不太好聽

做知識庫這件事,我一開始以為它是一個整理的問題:東西都在,只是亂,把它們歸位就好。

實際上它有很大一部分是搶救的問題。

有些東西不是亂,是正在消失。而且消失的方式很安靜——沒有錯誤訊息、沒有警告、沒有人按下刪除。

它只是跟著一個人走了,然後某一天有人問起,發現已經沒有人能回答。


明天:那抓下來的東西,長什麼樣子

講完了資料從哪裡來,明天講它變成了什麼。

一份 5 MB 的檔案,裡面裝的是所有能抓到的事實。而設計那份檔案的時候,只有一個問題比別的都重要:

每一條事實,要帶什麼欄位,才能讓我事後追得回去它從哪裡來?


上一篇
# Day 17 — 我本來想做 fine-tune,而勸退我的是 AI 自己
下一篇
# Day 19 — 5 MB 的事實檔:每一條都要能指回它從哪裡來
系列文
它說得頭頭是道 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言